The present invention relates to model transformation, and in particular, to customizable model import and export to and from extensible markup language (XML) schema formats.
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
A model is a representation of the structure and/or behavior of an application or system. A representation is based on a language that has a well defined form (“syntax”), meaning (“semantics”), and possibly rules of analysis, inference, or proof for its constructs. The syntax may be graphical or textual. For building a concrete model, some infrastructure is needed, for example how should the semantics look, etc. A metamodel may be used to make a language for model. Metamodeling is the process of designing languages through meta and meta-meta notations. These notations help to ensure syntactically correct specifications as well as in the construction of customizable modeling. The idea behind metamodeling is to provide Tool and Data interchange between many different tools.
The state of the art in metamodeling is using a fixed metamodel for a specific area. With the rapid changes in business logic, the need for freely created metamodels is growing up with the rapid changes in business logic. In answer to this demand for modeling, the Object Management Group (OMG) has introduced the concept of a Meta Object Facility (MOF) in the framework of a model driven architecture (MDA).
The MOF is the OMG's adopted technology for defining metadata and representing it as common object request broker architecture (CORBA) objects. An MOF metamodel defines the abstract syntax of the metadata in the MOF representation of a model. The MOF model itself describes the abstract syntax for representing. MOF metamodels can be represented using a subset of unified modeling language (UML) syntax. The MOF Model is made of two main packages (in MOF 2.0): essential MOF (EMOF) and complete MOF (CMOF).
FIG. 1 is a block diagram of the four level hierarchy of metamodeling in MOF. The four levels are the M0 level 102, the M1 level 104, the M2 level 106, and the M3 level 108.
The M0 level 102 contains the run-time instances of the user. The instances have data that is used by the instances. The instances can be in different forms, for example as databases. The elements of the M0 level may be generally referred to as “data”. Specific examples of M0 instances include a customized order management process and a specific purchase order.
The M1 level 104 contains models, for example, a UML model of a software system. Each element in the M0 level 102 is an instance of an element of the M1 level 104. M1 elements directly specify what instances in the M0 world look like. The M1 level is the traditional understanding of a “model”. The elements of the M1 level may also be generally referred to as “metadata” (since they are “meta” to the “data” of the M0 level). Specific examples of M1 elements include the web service description language (WSDL), an order management process component, and a purchase order business object.
The elements that exist at the M1 level 104 (for example, class, attributes, and other model elements) are themselves instances of classes at the M2 level 106. An element at the M2 level 106 specifies the elements at the M1 level 104. The same relationship that is present between elements of levels M0 and M1 exists between elements of M1 and M2. Every element at M1 is an instance of an M2 element, and every element at M2 categorizes M1 elements. The model that resides at the M2 level is called a “metamodel” (since it is “meta” to the “model” of the M1 level). UML, extensible markup language (XML) schema definition (XSD), and common warehouse metamodel (CWM) are examples of such languages. Specific examples of M2 metamodels include process components, business objects, and integration scenarios.
Every element at M2 is an instance of an M3 element, and every element at M3 categorizes M2 elements. The M3 level 108 defines the concepts needed to reason about concepts from the M2 level 106. Within the OMG, the MOF is the standard M3 language. All modeling languages (like UML, XSD, CWM, and so on) are instances of the MOF. The elements of the M3 level may be generally referred to as “meta-metamodels” (since they are “meta” to the “metamodels” of the M2 level).
Another example of a MOF is SAP's Modeling Infrastructure (MOIN). MOIN is a development project within SAP's NetWeaver organization. One aspect of the MOIN project is to implement the platform for SAP's next generation of modeling tools.
Eclipse is an open source community whose projects are focused on building an extensible development platform, runtimes and application frameworks for building, deploying and managing software across the entire software lifecycle. Eclipse project categories include enterprise development, embedded and device development, rich client platform, rich internet applications, application frameworks, application lifecycle management (ALM), and service oriented architecture (SOA).
The Eclipse modeling framework (EMF) is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in extensible markup language (XML) metadata interchange (XMI), EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Models can be specified using annotated Java, XML documents, or modeling tools like Rational Rose, then imported into EMF. EMF is another example of an M3 level model.
Given two types of M3 level models, for example MOIN and EMF, it is desirable that metadata created with one type of M3 model be accessible by the other type of M3 model. Current implementations of integration tools are lacking in ease of use, and it is cumbersome to implement new integration tools for additional metamodels. EMF provides a default mapping for importing XSD to EMF metamodels but does not allow the developer to influence the generated models manually; for each M2 metamodel, a model importer has to be written manually to import M1 instances and make them compliant with the M2 metamodel.
As another example, EMF currently only generates a trace (mapping) that is used only for informational purposes and is not used any further. Given the EMF trace (mapping), a developer must program a complete importer function to import a M2 metamodel into MOIN without having any reuse option.
Thus, there is a need to reduce efforts for writing import and export tools for model component integration purposes. More specifically, there is a need for processing instances of metamodels at the M2 level to create corresponding M1 instances.
Thus, there is a need for improved model integration tools. The present invention solves these and other problems by providing an apparatus and method of customizable model import and export to and from XML schema formats.